benchmark?

Sorry, no benchmarks. That is optimization for server client's - read article carefully! (Last time I'd posted that pull request - I missed that fact)

Basically, if you're sending large chunks - browser can display parts of page before it stop receiving, b/c part of chunk can't be encrypted.

BTW, try this in Chrome:
https://donnerjack13589.dyndns.tv:8081/

It's nodejs SPDY server :) And it's sending data in 1500 bytes chunks

I'm concerned about the effect this might have on throughput, and thats what it would be nice to have a benchmark of -- showing the effect is negligible.

1500 byte writes to SSL_write also would cause a bad behavior for many connections, because that would become 1500+ bytes with the TLS headers/protocol, and for most MTUs would end up being 2 packets instead of 1. (good thing to look at in wireshark over non-localhost)

If the benchmark shows this isn't a huge drop in throughput, I'd be interested in seeing what happens with using ~1300-1400 byte writes, which should drop you bellow the common MTUs.

Hm... Nice point, @pquerna.

Mike has told me to use 1400 bytes, but I'd seen 1500 in chromium's flip_server - so I decided to use last one...
Probably that was wrong step.

Can you please help and perform some tests?

I think we should come back to this issue, splitting can't be done in userland

Reconsider?

Can one of the admins verify this patch?

fuck it.

fuck it.

@indutny you should be more friendly to pull request submitters ;P

Is it a special command for jenkins?